|
This page last changed on Jul 13, 2007 by kgomes.
Taking the text from the 2008 Abstract, an outline for the presentation might look like:
Outline
- SSDS Requirements Under MOOS
- Store data streams from MOOS instruments
- Store and manage instrument metadata (catalog) for MOOS
- Track instrument lifecycles
- Operational Health and status
- Query catalog for data discovery
- Make data available (generally) in raw, transformed and post processed formats
- Provide metadata/data added value
- Track data provenance
- Current SSDS status (meeting the requirements)
- Raw data available and keeps legacy programs in tact.
- All instrument metadata cataloged in SSDS
- MOOS Data/metadata management for:
- M0 Mooring (CIMT)
- MTM1 Mooring (Closed)
- MTM2 Mooring (Closed)
- MTM3 Mooring (Closed)
- MSE Mooring (all four nodes)
- M0 Mooring processing/provenance tracked
- MSE Mooring processing/provenance tracked
- SSDS Beyond MOOS
- Data/Metadata management for:
- M1 Mooring
- M2 Mooring
- AUVCTD
- Bruce Howe's Aloha Mooring CTD and flourometer (ADCP will be soon).
- AUVCTD metadata cataloged, raw data transformed, data provenance tracked
- OASIS Mooring data and metadata stored and cataloged, data provenance tracked
- Bruce Howe's Aloha Mooring (Puget Sound) data and metadata cataloged
- Uniqueness in the Community and external impact
- Large amount of effort goes into
- Most "data applications" rely on some structured data and focus more on specific analysis of data
- With some form of observatory middleware (like SIAM), SSDS can track and present the operational aspects of the observatory (instrument lifecycles)
- Data provenance is something that is lacking severely. Workflow tools exists, but rely on existing services and ties them together (SSDS provides those services and metadata to make workflow go). Most tools work on user's constructing data provenance and saving them, not dynamically tracked by system.
- Evidence of this is that SSDS is specified as a component for the ORION CyberInfrastructure.
- Future for SSDS
- SSDS has demonstrated value outside of MOOS
- SSDS makes internal data management easier (core data stream management easier 1 person can do work of 3-4 developers).
- Manage more of our internal data
- Track more data processing.
- Move more core data to SSDS.
- What are we hoping to do?
- improving metadata editing capabilities and client applications
- redeploying database integrity checking
- providing more useful and concise query and operational views of data producing systems
- maintaining our existing and growing archive of data and metadata
- distributing SSDS as an open source project
My guess for questions (and some thoughts on answers)
- How does this work support the strategic plan?
- I extracted the relevant points from the strategic plan at the bottom of this page. I think you can probably answer them but if we want to hash over them some more, we can.
- How is this related to the Data Aggregation proposal? I also included some answers below to the Criteria used for project evaluation. Feel free to add/remove.
- Data Aggregation is focused on taking curated data products and attaching powerful interfaces on top of them. Data Aggregation will not cover the operational aspects of ocean observatories. They don't care about engineering of operational data. SSDS should provide base data from which Data Aggregation will derive its tailored data sets from.
- Why haven't we made more progress on science related user interfaces?
- Science requirement for MSE were very difficult to extract (some instruments were new to scientists) and a large portion of the SSDS time for 2007 was used by other software components in MOOS.
- What is SSDS' role in the ORION CI work?
- It is largely going to be used for metadata capture and catalog for observatory and instrument information and life cycle. It will capture and store observatory and instrument metadata (and some data) and make available to the CyberInfrastructure and it's users.
- What is the status of the Asset Tracking work?
- Close to being finished and will finish during the last half of 2007 (2007 was extremely front loaded with other projects). Asset tracking helps support this follow on work.
- How much time will be requested?
- Largely this will come out of the proposal writing, but we should have some guess here (30 days me, 30 days you? ... total SWAG at this point).
- Will this be the last year of the project? (or, when will SSDS be 'done'?)
- Not this year, but we see future development being to support direct user requests, not infrastructure. Work on SSDS most likely would be line items in other projects to support domain specific aspects or requests.
- Has anyone else showed interest in SSDS?
- Yes, Dalhousie is interested in it for observatory management and SOPAC was interested in the cataloging component for managing bathymetry.
Criteria
This will be an infrastructure project. The criteria for infrastructure project evaluation is the following:
- Importance: Does the project address an important problem in oceanographic research?
- There is a gap between ocean instrumentation and data management systems and applications
- SSDS (with SIAM) has been filling that gap
- Automatic capture of all metadata
- Capturing data provenance
- Uniqueness: How unique is this contribution and well-suited for undertaking at MBARI?
- Not really an undertaking, but it operational at MBARI
- Due to its uniqueness it is being considered as a component in the ORION CI IO and external interests (Dalhousie, SOPAC)
- Timeliness: Why should this project move forward now? What are the drivers?
- This is the year to break SSDS out of MOOS and have it stand on its own legs.
- It is clearly an operational component, while the future of other MOOS technology is not clear
- This is the year to include non-MOOS inputs/outputs to make it a easier to use institutional asset
- Strategic Plan: Does the project demonstrate relevance to MBARI's strategic plan?
- Yes, particularly transfer of knowledge to external community.
- Particularly well position to help with OOI (both CI and CGSN if we win)
- Facilitates the response to opportunities to pass on data and understanding gained in pursuit of MBARI's research plan to organizations overseeing the environmental health of Monterey Bay and other locales
- The Team: Is the team appropriate for the work, are they available, and are they committed?
- Team would consist mainly of Kevin Gomes and Mike McCann (with support from others as more data streams are integrated)
- Prior Productivity: Has the project leadership been successful with prior support?
- SSDS has been successful to date and is the reason we are seeking to push SSDS outside of the MOOS envelope
- Does the project demonstrate improvements in operation from year to year?
- Yes, this past year has seen large improvements in robustness and support for MSE development team. Many processes are moving to depend on SSDS (Mike's processing, Fred's OASIS - M0, M1, M2, NDBC Export, UW/Aloha mooring, WHOI used for MTM3 cable)
- Does the effort have a significant impact on an important MBARI activity?
- Yes, currently supporting M0/CIMT, M1, M2, AUVCTD, UW, MARS/SENSORS Prototype, Could impact CGSN award and serve as bridge between CGSN development and CI development.
- Does the project team periodically assess the needs or requirements of its beneficiaries?
- Definitely, we are constantly fielding requests from Engineering, Operations, Science, and the external community, but we are limited to respond by resources.
- Will the effort benefit a large number of users?
- Operations: Better instrument management and operations status monitoring
- Science: More/Better interfaces to find and utilize data and associated processing and resources
- Support Engineering: Cut time to manage mooring data streams and data availability to outside community
- External community: get SSDS code base out there (this also cuts our time to fields requests from the community).
Salient points from the Strategic Plan:
- Our capacity for understanding the complexity of the ocean, and for forecasting a realistic view of its future that we will partially create, is limited by the lack of technology for observing the ocean and maintaining a sustained presence in that harsh environment.
- Goal: Transform and advance understanding of the most significant unsolved problems in oceanography by developing, adapting, and demonstrating innovative technologies.
- Goal: Utilize those developments to discover and understand how the natural system operates, responds to, and interacts with anthropogenic influences.
- Goal: Transfer the knowledge gained and the technology developed to communities outside of MBARI, including policy makers, government laboratories, resource managers, and the public.
- MBARI technology is in demand for adoption by groups external to the institution, and that demand is met through external partnerships, licensing, copying, or other strategies as appropriate.
- Look at: Natural rhythms of the complex ocean systems (Box 4), such as quantifying and understanding variability in the ocean food web on the seasonal, El NiƱo, and North Pacific Decadal Oscillation (PDO) time scales (emphasize time-series here).
- Research Actions: Develop a data archive for Monterey Bay that can be easily accessed by users who are not data providers and which can be integrated seamlessly with related data sets from the larger oceanographic community.
- Strategy B1: Participate in national initiatives that are aligned closely with MBARI's strategic plan and technology developments (Box 9), such as the National Science Foundation's Ocean Observing Initiative and National Oceanic and Atmospheric Administration's Ocean Exploration Program.
- Strategy D2: Be alert for opportunities to pass on the data, models, and understanding gained in pursuit of MBARI's research plan to organizations overseeing the environmental health of Monterey Bay and other locales. (Box 11).
|